iT邦幫忙

10

閱讀程式

Pieta 2022-05-28 02:01:0513971 瀏覽
  • 分享至 

  • xImage
  •  

https://ithelp.ithome.com.tw/upload/images/20220528/20149394F59pBPMDDE.jpg

前言

Clean Code,老聖經一本,是一本如何撰寫大家都能輕易看懂的Code,當中最重要的是閱讀程式,因此特別開一篇文章聊一聊閱讀程式,主要是未來希望能拿來當教育訓練用的文件。
以下會用一個題目當範例,當然這也是我常用的面試題,並在後續留下常見的解,請各位體驗一下,何謂閱讀程式。

5/28 09:30對於許多內容增加了語意修正,解釋。

題目

這是會議過後,PM給的客戶需求,需求為:
完成以下閏年的規則的Function,無論語言。

  1. 公元年分非4的倍數,為平年。
  2. 公元年分為4的倍數但非100的倍數,為閏年。
  3. 公元年分為100的倍數但非400的倍數,為平年。
  4. 公元年分為400的倍數為閏年。

答案

以下會列出常見的幾種答案,並且在下面註解用中文閱讀的狀況。

答案1

function isLeap(year) {
  return ((year % 4) === 0 && (year % 100) !== 0) || (year % 400) === 0;
}
  1. 公元年為4的倍數 且 公元年非100的倍數, 或 公元年為400的倍數,為閏年。

答案2

function isLeap(year) {
  if (year % 4 === 0 && year % 100 !== 0) return true;
  else if (year % 400 === 0) return true;
  else return false;
}
  1. 公元年為4的倍數 且 公元年非100的倍數,為閏年。
  2. 公元年為400的倍數,為閏年。
  3. 剩下則為平年。

答案3

function isLeap(year) {
  if (year % 4 === 0) {
    if (year % 100 === 0) {
      if (year % 400 === 0) {
        return true;
      } else {
        return false;
      }
    } else {
      return true;
  } else {
    return false;
  }
}

如下圖:
https://ithelp.ithome.com.tw/upload/images/20220528/20149394OFnqLzliQL.png

答案4

function isLeap(year) {
  if (year % 400 === 0) return true;
  else if (year % 100 === 0) return false;
  else if (year % 4 === 0) return true;
  else return false;
}
  1. 公元年為400的倍數,為閏年。
  2. 其他公元年為100的倍數,為平年。
  3. 其他公元年為4的倍數,為閏年。
  4. 其他公元年,為平年。

答案5

function isLeap(year) {
  if (year % 4 !== 0) return false;
  if (year % 4 === 0 && year % 100 !== 0) return true;
  if (year % 100 === 0 && year % 400 !== 0) return false;
  if (year % 400 === 0) return true;
}
  1. 公元年分非4的倍數,為平年。
  2. 公元年分為4的倍數但非100的倍數,為閏年。
  3. 公元年分為100的倍數但非400的倍數,為平年。
  4. 公元年分為400的倍數為閏年。

答案6

function isLeap(year) {
  if (year % 4 !== 0) return false;
  else if (year % 100 !== 0) return true;
  else if (year % 400 !== 0) return false;
  return true;
}
  1. 公元年分非4的倍數,為平年。
  2. 其他公元年為非100的倍數,為閏年。
  3. 其他公元年為非400的倍數,為平年。
  4. 其他公元年,為閏年。

分析

個人會選擇答案5或答案6,原因是,今天PM、客戶,在會議後,提出了非常明確的需求,我不建議去做轉換(換句話說),這樣的行為在我的工作經驗中,是具有高風險的,非常常看到,難解的邏輯bug都是放在這種狀況內,如果一開始就選擇答案5、答案6去撰寫程式,一來你會code會完成的非常快,因為只做翻譯;二來不可能失誤,會失誤的話,PM、客戶剛開始就是錯的,如果真的不滿意這樣的需求,也應該透過會議討論修正。

效能爭議

對於效能爭議,我認為這個爭議是非常小的,原因如下:

  1. 無論如何撰寫這題目永遠會是三層判斷。
  2. 若編譯上面的所有答案,編譯結果都會非常接近。
  3. 在討論演算法時,通常是討論倍數、指數的效能問題,而非討論一行兩行的效能優化。
  4. 根據我的工作經驗,更多時候在討論效能問題前,更常見的是程式過度術語化、複雜化,造成商業上損失的bug,更為常見,個人是提倡清楚的Code、降低Bug,而非效能擺在第一位。
  5. 確實有個缺點,在類似JS的環境中,你會將整個檔案傳送到前端運行,語句的長短,會影響到傳輸的效能,但個人認為比起bug這樣的缺點值得的。

結語

這是我第一次在iT邦幫忙發文,未來是否發文,就看有沒有我現實工作上討論到爛掉的話題了,謝謝大家。


圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

2 則留言

0
rainbowrain
iT邦新手 2 級 ‧ 2022-06-08 10:47:53

只按 Like 不太夠力 XD 謝謝分享!希望大大能多分享這樣的文章

0
akajoke
iT邦新手 5 級 ‧ 2023-01-07 20:10:00

好文章收藏 大推

我要留言

立即登入留言